home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 237 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. Date: Wed, 1 Jun 94 16:24 BST-1
  2. From: Andre Willey <andre@cix.compulink.co.uk>
  3. Subject: Re: Shortcut Manager
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.262762@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9. In-Reply-To: <9406011316.AA06508=avg@mijt.cwi.nl>
  10.  
  11.   > That's why I suggested a wind_get or cookie call instead of the fishy
  12.   > resource editing stuff:  you can make changes globally.  Now if you
  13.   > add some kind of separation between types of application (editor,
  14.   > word, graphics, compiler) then all applications should be happy as
  15.   > well). 
  16.  
  17. Better still (and trying to avoid over-thinking the plumbing, if possible)
  18. how about a system text file, rather like ASSIGN.SYS, NEWDESK.INF, etc,
  19. which contains the user's preferred shortcuts. A default file could be
  20. created which pretty much mirrors the contents of our final standard - or
  21. indeed *is* the final result of our work? The user could then change their
  22. own local copy as required - for example to allocate 'Select All' to some
  23. other key sequence. :-)
  24.  
  25.  
  26. Each application which supported this new system would simply read the text
  27. file during its installation process, and pick out any shortcuts that it has
  28. a use for.
  29.  
  30. For example, a small section of this proposed SHORTCUT.INF file:
  31.  
  32.   0 ^Q ; Quit
  33.   1 ^A ; Select All
  34.   2 ^W ; Cycle Windows
  35.  
  36. The code numbers at the start of each line would be defined as part of our
  37. spec, and used by each application to determine what type of command is being
  38. defined on each line. The comment after the ';' would thus be for user-
  39. information only, and could be in any desired language - the code and the
  40. keypress are all that would be needed to parse the file.
  41.  
  42. Thus a program would parse the above file, and if the program supports a
  43. 'Quit' option, it would assign the shortcut ^Q to it. Any specialised features
  44. which are not defined in the shortcut file would not be reassigned from the
  45. program's defaults (unless a conflict occurs, in which case the user should
  46. be warned).
  47.  
  48. This strikes me as both very simple and yet very flexible. It would be easy
  49. to add new options to the standard (via this list) as new features are
  50. designed - but only programs which support a given feature would bother to
  51. check the shortcuts file for it. It's also so simple that even a user could
  52. understand it - although a nice neat editor could be written if desired.
  53.  
  54. Any comments?
  55.  
  56. Andre
  57.  
  58.  +------------------------------------+-------------------------------+
  59.  |            Andre Willey            |  Cygnus Software Development  |
  60.  |  Email: andre@cix.compulink.co.uk  |  Sutton Coldfield -- England  |
  61.  |   or: ...{mcsun}!uknet!cix!andre   |  Tel:  (UK/+44) 021 308 5251  |
  62.  +------------------------------------+-------------------------------+
  63.